home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1080 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.9 KB

  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: clamage@Eng.sun.com (Steve Clamage)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Use of standard exception classes
  5. Date: 15 Apr 1996 02:47:30 GMT
  6. Organization: Sun Microsystems Inc., Mountain View, CA
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <4kr853$785@engnews1.Eng.Sun.COM>
  9. References: <9604121530.AA08606@sun132.spd.dsccc.com> <gregorDpsBEt.Dw0@netcom.com>
  10. NNTP-Posting-Host: taumet.eng.sun.com
  11. X-Nntp-Posting-Host: taumet.eng.sun.com
  12. X-Newsreader: NN version 6.5.0 #21 (NOV)
  13. Content-Length: 2026
  14. Originator: clamage@taumet
  15.  
  16. gregor@netcom.com (Greg Colvin) writes:
  17.  
  18. >>Another developer on our team has asked
  19. >>  How can we be sure that ANSI C++ library callbacks work
  20. >>  correctly in the face of exceptions?  What if ANSI C++
  21. >>  library code catches *our* exception?
  22. >>
  23.  
  24. >Not to worry.
  25.  
  26. >>Is this a problem, or are library functions required to reraise any
  27. >>exceptions thrown by client code? 
  28. >>
  29.  
  30. >Client exceptions are intended to be pass through library code uncaught, or
  31. >at least reraised.
  32.  
  33. I don't find that requirement in the draft. Perhaps I missed it.
  34.  
  35. In general, it seems to me that if a callback function throws an
  36. exception that must be diagnosed as due to that callback and not to
  37. anything else, that exception should not be derived from other
  38. exceptions. Otherwise ALL exception-handling code must be rather
  39. elaborate just in case some such callback might be involved (e.g.,
  40. in a library you use but didn't write).
  41.  
  42. Every exception handler would have to determine whether the actual
  43. exception was in fact derived from the exception it thought it
  44. was handling, and rethrow it instead of handling it. (The current
  45. function might not call a callback function, but one of the functions
  46. it does call might have done so.) If you have to write all your code
  47. like that, why use exception hierarchies at all?
  48.  
  49. I suspect it is typically the case that the callback can in fact throw
  50. a derived exception without causing any difficulities. The callback
  51. is in a sense part of the implementation of the called function,
  52. and the problem it finds typically can be thought of as coming from
  53. the called function.
  54.  
  55. For example, consider a "get_data" function that has takes a callback
  56. to retrieve bytes from somewhere. If the callback encounters an error,
  57. it is probably sufficient to throw an exception the get_data function
  58. might have thrown on its own. The caller of get_data likely doesn't
  59. care which sub-function found the problem, but only whether the
  60. call succeeded or what class of error was found.
  61.  
  62. --
  63. Steve Clamage, stephen.clamage@eng.sun.com
  64.  
  65.  
  66. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  67. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  68. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  69. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  70. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  71.